As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more information handling systems, data storage systems, and networking systems.
A thin client, or as it is sometimes referred to a lean client or a slim client, is an information handling system or an executable software program running on an information handling system. A thin client generally relies on another information handling system, such as a server, to fulfill at least some of the requested computational roles. For example, a user can access applications or other computational support services from a server by logging into the server from a thin client, for example, a terminal device. Multiple users may log into the same server from multiple terminal devices and may simultaneously request services from the server.
A user may connect a particular universal serial bus (USB) device to a local client device. Many USB devices fall within well-defined device classes, for example, mass storage devices. When devices fall within these well-defined classes, the operating system drivers or equivalent provide all necessary support for the USB device functionalities at the kernel-level itself. When the USB device does not fall within one of the well-defined device classes, the vendor for the USB device provides the necessary support for the USB device either through one or more applications, kernel drivers, etc. Many times the vendor will provide the necessary support via an application and a minimal driver. In general, the application will communicate with the USB device by issuing certain USB request block (URB) commands to the USB device driver. The driver posts the request associated with the command to the USB device from the same thread initiated by the application. That is, the application memory associated with the command and the USB device remains valid.
A problem arises when a USB device is connected by a user that is not within a well-defined class and that USB device is redirected to a server where the USB device is virtualized. When such vendor-specific USB devices are redirected, all the requests associated with the USB device will be queued and serviced in an arbitrary thread. This results in the USB device not functioning properly with the USB redirection/virtualization software.